What’s New in SQL Server Web Services
Microsoft first made it
possible to expose T-SQL query batches, stored procedures, and
scalar-valued functions as web services with the release of SQLXML 3.0,
an add-on package for SQL Server 2000 that allowed for the interchange
of relational data as Extensible Markup Language (XML).
Over the past few years, the
SQLXML packages have addressed the growing dependence of data-driven,
distributed applications on XML and have kept SQL Server 2000 current
with the explosion of progress in the world of XML.
The good news is that we no
longer need SQLXML to create SQL Server web services because SQL Server
2008 supports them natively. The bad news is that this feature has been
deprecated in SQL Server 2008. Although it is true that sometimes SQL
Server features are deprecated for several versions before being
removed, it seems more likely that native web services will be removed from the next version of SQL Server due to security concerns.
Web Services Migration Path
Although SQL Server 2008
supports native web services, it’s important to plan your migration path
to another web service technology as soon as possible. The first step
in moving away from this technology is to identify your web service
endpoints. There are several ways to accomplish this. The easiest is to
use SQL Server Upgrade Advisor, which includes deprecation warnings in
its reports. SQL Server’s installer generates warnings when you upgrade
from SQL Server 2005 to 2008. The database engine generates warnings
(such as “Avoid using this feature in new development work”) upon
service startup and when you create HTTP endpoints using SQL Server
Management Studio (SSMS) or a similar tool. You may also view
deprecation warnings generated at runtime using SQL Profiler (be sure to
include the Deprecation: Warning event in the properties of your trace template).
Now that you know how to
identify your endpoints, the next step is choosing a replacement
technology. Microsoft ASP.NET provides comprehensive support for web
services, as does Windows Communication Foundation (WCF). There are also
a number of related technologies to choose from, such as services
developed using Representational State Transfer (a.k.a. RESTful
services) and ADO.NET Data Services (formerly known as Astoria).
The choice is really about what works for you, your organization, and
your applications. Discussion of these technologies is beyond the scope
of this book. SQL Server web services generates runtime errors or
produces unexpected behaviors if the underlying data transmitted by the
service is typed as one of the newly introduced SQL Server 2008 data
types, such as date, time, hierarchy_id, datetime2, datetimeoffset, geometry, or geography.
If you use these data types
either in results returned by a stored procedure (exposed via an
endpoint), or in its input parameters, SQL Server generates a SOAP fault
at runtime. These types also end up commented out of the types section
of the WSDL that SQL Server generates for your web services. All data
types supported by SQL Server 2005, however, continue to work as
expected.
In the following sections,
we describe how to develop web services using SQL Server 2008 (or SQL
Server 2005). Keep in mind that the services you build, while supported
today, may not be supported in the near future.
Web Services History and Overview
Web services are supported
on most major software platforms and can be built using Integrated
Development Environments (IDEs) that comply with a few key World Wide
Web Consortium (W3C) recommendations:
Web Services Description Language (WSDL)— WSDL is the XML grammar used to specify the functions and types (known as its interface) of a web service.
Simple Object Access Protocol (SOAP) 1.2— SOAP is the network transport-layer protocol for web services.
Until
now, Open Database Connectivity (ODBC) and Tabular Data Stream (TDS; a
proprietary protocol developed by Sybase) were the only means available
for clients to access SQL Server data. But because the web service
standards are nonproprietary (although there are proprietary
extensions), web service clients don’t need to install Microsoft Data
Access Components (MDAC), ODBC, SQL Server Client Tools, or any open
source variants of these.
The Web Services Pattern
Web services follow a
stateless request/response model that corresponds directly with the
client/server model of Hypertext Transfer Protocol (HTTP). The following
summary illustrates this programming pattern:
A client
application discovers that a server application hosts a web service that
exposes one or more web methods. This process, known as discovery, is accomplished in one or more of the following ways:
Microsoft’s
Universal Description, Discovery, and Integration (UDDI) service, an
online catalog for publishing web services, facilitates this process.
More
commonly, the developer of the hosted web service provides the network
address and web method descriptions to the developer of the client
application that will consume it (that is, call its methods). This is
still the dominant way web services are exposed because most provide
data that is strictly confidential.
The
client then asks the discovered web service to describe its methods and
their types, parameters, and return values, using the standard WSDL XML
vocabulary. This is usually performed via an HTTP request to the web
service in the form http[s]://ServerDomainName/WebServiceName?wsdl.
The web service responds by providing the WSDL (an XML document).
The
client application (or, in some cases, the IDE of the client, such as
Visual Studio) creates a code class based on the server-generated WSDL.
This class is known as a stub, or proxy,
because it merely contains callable references to the actual remote
methods of the web service, wrapped in the formal language semantics of
the client’s software platform. (The actual implementation of those
methods is held on the server application.)
The
client invokes a web service method over some protocol (usually HTTP).
This invocation is an HTTP request encoded in the SOAP XML vocabulary.
The web service responds (it is hoped) with a SOAP-encoded response.
Note
Content and metadata pertaining to these stateless communications are always encoded in XML-tagged documents known as SOAP envelopes. For complete information on SOAP, visit the SOAP messaging framework specification, available online from the W3C, at www.w3.org.
The W3C is the
organizational body responsible for creating and maintaining World Wide
Web standards, including XML. The W3C website is a great place to get
accurate and up-to-date information on Web standards.
To recap: UDDI or
word-of-mouth provides a discovery mechanism for web services. WSDL
provides the web methods, types, and metadata of the web service.
Stateless requests and responses are invoked over HTTP (or perhaps TCP)
and transmitted in SOAP-encoded format.
Before SQL Server 2005,
developers had to use the Internet Information Services Virtual
Directory Management (IISVDM) for SQL Server utility to create
SOAP-typed virtual names to expose their data. (Incidentally, this could
also be accomplished using a language such as Visual Basic .NET with
the SQLVDir object model that came with IISVDM.)
Today, this process is far
easier. SQL Server no longer relies on IISVDM or even IIS to publish web
services. It ties directly in with operating-system–level (or kernel-mode) HTTP, listening by way of the HTTP API (sometimes referred to as http.sys).
This means that under the covers, SQL Server registers the virtual
paths (also known as URIs, such as www.myserver.com/urlpath) specified
in endpoint creation syntax with http.sys
in the same way that IIS registers virtual directories. The operating
system then farms out incoming HTTP requests to IIS or SQL Server, based
on the path of the incoming request.
SQL Server also includes
the entire SOAP messaging stack in its binaries. You might say that to a
certain degree, SQL Server is now a web server with limited
applications.
